\chapter{Base de données}

\section{Base de données Interne}

\subsection{Diagramme d'entités-relations (précédente version)}
\begin{center}
\includegraphics[scale=0.67]{schema_relationnel_bdd_interne}
\end{center}

\subsection{Diagramme d'entités-relations (version finale)}

\begin{center}
\includegraphics[scale=0.67]{schema_relationnel_bdd_interne_final}
\end{center}



\subsection{Explications}

La base de données interne de SPASS est celle qu'utilise le \textit{core} pour stocker toutes les données nécessaires au fonctionnement de ses services. Il n'y aucune gestion de droits dans cette base, elle devait intervenir dans la base de données externe qui sera détaillée dans la section suivante.

\subsubsection{Changement intervenus en cours du développement}
L'architecture préliminaire de SPASS introduisait une base de données interne à 7 tables (schéma 6.1.1). En effet les tests, les scripts (de test) ainsi que les ensembles de scripts étaient stockés dans la base de données. L'architecture finale (schéma 6.1.2) rend les choses plus simple, étant donné que les tests sont stockés dans des scripts, eux mêmes stockés dans des répertoires. La hiérarchisation des tests, scripts et testsets en répertoires et fichiers rend leur présence dans les tables de la base de données inutile, un testset devenant un répertoire, un script de tests un fichier python, la copie de cette arborescence dans chaque \textit{template} permet de les charger dynamiquement depuis la \textit{warehouse}.

\subsubsection{Présentation des tables}

\textbf{Template} : Cette table va permettre de répertorier tous les \textit{template} disponibles pour les \textit{assignment}, elle doit être tenue à jour à chaque ajout, modification ou suppression de \textit{template}. Pour chaque entrée de cette table un certain nombre d'informations sont stockées comme le titre (ex: Projet, Devoir Maison, Td, Mini-Projet etc ...), la durée, etc...

\textbf{User} : C'est la table qui permet de stocker chaque utilisateur pouvant interagir avec SPASS. Initialement, seuls les noms et prénoms sont fournis dans cette table, mais d'autre champs pourront bien évidemment être rajoutés lors de l'extension de SPASS, selon les besoins. Chaque utilisateur reste unique, l'unicité étant pour l'instant définie par le couple (nom, prénom).

\textbf{Team} : C'est la table qui permet d'associer les utilisateurs (étudiants) au sein d'un même groupe. Typiquement les étudiants associés à la même clé (\textit{id\_team}) font parti du même groupe. Faîte ainsi, la table ne rencontre aucune difficulté à associer un étudiant à plusieurs groupes.

\textbf{Team\_Set} : Cette table permet d'associer plusieurs groupes afin de former un ensemble. Ainsi on choisi d'associer un unique ensemble de groupes à chaque \textit{assignment} plutôt que de fixer un nombre de groupes maximum au système. Cette solution a l'avantage d'être souple, on peut retirer ou ajouter une équipe à un \textit{assignment} en ne modifiant que cette table.

\textbf{Assignment} : C'est la table centrale de cette base de données, elle associe à chaque entrée un \textit{template}, un enseignant (\textit{user}) ainsi qu'un ensemble de groupes d'étudiants (\textit{Team\_Set}). 

\subsubsection{Interaction avec la base de données externe}

La base de données interne n'introduit pas la gestion des droits, elle
est cependant auto-suffisante à l'interface par ligne de commande où
l'utilisateur connecté a de facto tous les droits. Cependant pour une
exploitation complète du système par une interface conviviale, comme
l'interface web prévue, il est nécessaire d'introduire une gestion des
droits pour différencier les utilisateurs durant leur connexion au
système. \textit{Django} dispose d'une gestion des droits
particulière. Il utilise le modèle (le code de notre \textit{core}) pour générer
automatiquement l'ensemble des droits (expliqué en détail dans la
section suivante). Pour associer chaque utilisateur à un groupe de
droits, il dispose de sa propre table \textit{user} qu'il va falloir
synchroniser avec la table éponyme de la base de données interne.

\section{Base de données Externe}

\subsection{Diagramme d'entités-relations}
\begin{center}
\includegraphics[scale=0.70]{schema_relationnel_bdd_externe}
\end{center}

\subsection{Explications}

La base de données externe est celle que devait utiliser l'interface web gérée par \textit{Django}. C'est la seule base de données qui introduit la gestion des droits d'accès. Pour ce faire, elle devait utiliser principalement deux tables, \textit{User} et \textit{Group} présentées ci dessus.

\subsubsection{Présentation des tables}

\textbf{User} : C'est la table que devrait utiliser \textit{Django} pour authentifier les utilisateurs, une grande partie des champs devraient être similaires avec la table éponyme de la base de données interne. Un nouveau champs \textit{id\_group} devrait faire son apparition, il permettrai d'associer chaque utilisateur à un groupe de droits dans la table \textit{Group} permettant ainsi de distinguer les utilisateurs connectés et de leur offrir le panneau de services associés à leurs privilèges.

\textbf{Group} : C'est dans cette table que devraient être créés les différents groupes d'accès (enseignants, étudiants etc ...). La gestion des droits introduite par \textit{Django} est liée au modèle utilisé (les services du \textit{core}), un droit correspond à la permission d'appeler une fonction ou une méthode. L'ensemble des droits est généré automatiquement par \textit{Django} à partir du modèle. Un groupe serait créé en associant un certain nombre de droits (appels aux fonctions ou méthodes) à un nom de groupe (ex: Teacher, Student etc ...) et une à clé \textit{id\_group}. Cela se fait par l'interface administrateur de \textit{Django}.

\subsubsection{Interaction avec la base de données interne}

Pour que cette base de données puisse fonctionner correctement, il faudrait que sa propre table \textit{user} et celle de la base de données interne soient synchronisées. Pour se faire, on pourrai automatiser la tache en faisant un appel aux deux tables pour chaque insertion ou modification, ou alors synchroniser l'ensemble des entrées à intervalle de temps régulier.
